
It felt as though we were getting nowhere that first 
night as we tried to discuss the problem. We were 
twenty-three people thrown together in a room, without 
a leader, and we didn't have anything to go on beyond 
what we had heard from Mike Sander. 

Finally, the class agreed on two things that we 
needed to accomplish immediately: One was to define 
the problem: the other was to define a process for 
accomplishing the task we had been given. 

We broke up into groups. In my group it was total 
chaos. Eventually, we managed to define the problem, 
but we completely failed to come up with any kind of 
process for getting things done. At that point, I started 
thinking that we only had three more nights to work on 
this. How' would we get anywhere if we didn’t even have 
a process? 

When we regrouped as a class, it turned out that 
we had all come up with similar definitions of the 
problem, but the processes were all over the map. It 
took us at least another hour to agree on the w'ording 
of a mission statement, and then we couldn't come to 
any agreement about what came next. I started to say 
we need a leader. Nobody was listening. So I kept 
saying, “We need a leader." 

Finally, someone said, “Well, why don't you be our 
leader?” It was classic. You know, I said, "We need this,” 


I looked at this thing with two agendas in mind. Agenda 
number one was to give the class a problem, which was 
challenging and stimulating. Agenda number two was to 
see if a bright group of people might come up with some 
notions about how to bridge these worlds of technology 
development and flight system development. 

We had actually been thinking about this problem for a 
couple of years, off and on. I thought, well look, here is 
an opportunity to get some bright folks who bring a lot of 
capability to the table. I’ll explain the problem to them 
and see if they can offer some fresh insights and ideas. 

It’s a very powerful process and one that we have now 
already put to use in MSL in a number of different areas: 
getting people who haven’t been in the middle of the 
forest, but are still very strong technically, to step in 
and think about the problem for a while and offer 
their observations. 

MIKE SANDER, let Propulsion Laboratory 


i 


2nd then they S2id r “Oksy, you do it.” I should have seen 
that coming — the old be-careful-of-what-you-ask-for 
scenario. We had a vote, and I became the leader. 


It was now my job to lead the discussion about how 
to proceed. It was clear to everyone that we would need to 
break into groups to accomplish anything. It took a while 
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NASA scientists and engineers demonstrate new 
robotic technologies that they hope to employ on 
the Mars Science Laboratory (MSL) at a “Marscape" 
test facility at Ames Research Center. 
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but we came to the consensus that each group would 
work the problem and present a solution, rather than 
dividing up the problem into pieces. As a class we would 
decide which of the solutions to present to Mike Sander. 

My plan was to go around the room, count off, and 
randomly select the three teams. It would be fast and 
easy. But as it turned out, there were people who felt 
strongly about working with other likeminded people. 
As a result, the class as a whole would attack the 
problem from different perspectives. So, we broke into 
teams that way. 

One group that emerged said, “Yes, we can do this. 
It’s not so hard." They were optimistic that they could 
put together a good workflow for the problem based on 

YOU HAVE TO LISTEN TO 
THE INPUT OF THE TEAM, 
OR YOU’RE GOING TO DO 
THE PROJECT HARM. 


their collective knowledge. It was simply a matter of 
identifying useful software that had already been 
developed and finding a way to evaluate and integrate it. 

Another group that emerged said, "No, we don’t 
think that's even been done successfully before. It's not 
a problem that we know how to solve at this point." 
They wanted to try to come up with some innovative 
ideas, push the envelope, and explore things that hadn't 
been tried before. 

Then there was a third group that kind of said, "You 
know, you guys are making such a big deal of this. Why 
don’t we just do it?" I called them the Nike group. It 
wasn't that they didn’t care about working the problem; 
they just didn’t see the point in all the philosophical 
discussions about approaches. They simply wanted to 
get to work. 

We spent quite a bit of time that next night getting 
organized. We came up with a plan for the rest of the 
week's schedule, how we were going to achieve this work. 
On a small scale, we were seeing demonstrated many of 
the things being taught in the class: the value of putting in 
time up front to define requirements, the need for flexible 
leadership, the importance of team building, and more. 


When it wa> time to divide up into teams, I joined with 
a group of people who, like me, felt the project 
assignment wasn’t as easy or straightforward as other 
people in the class made it out to be. Almost instantly, 
we were dubbed “the pessimists.” But I never felt that 
was an accurate description. 

I would like to think that a more accurate name for our 
group was “the realists.” We were simply saying that a 
major revamping of the mindset at NASA would need to 
occur to solve this problem we were handed. We didn’t 
think the assignment was trivial or easy to do; trying to 
recruit autonomy knowledge from the private industry and 
university sectors was an extremely difficult challenge. 

Everyone on our team had a software background. All of 
them, except for me, came from Ames — but none of 
them knew one another well. We got started with some 
brainstorming concepts that the folks from the design 
company, I DEO, taught us on the first day of class. I think, 
as a result, that we all felt comfortable sharing our ideas. 

We didn’t always remember to apply the rules they gave 
us (such as the one that says to “defer judgment”), but 
we did work collaboratively and courteously. Someone 
would draw an idea on the easel we were using, and 
then someone else would build on it Before long, our 
ideas began to coalesce. 

ROB TOAZ, Jet Propulsion Laboratory 

What became immediately obvious was that we had 
an amazing amount of technical expertise in that room. 

1 think that was another great lesson for me, just 
listening and seeing how divergent ideas that emerged 
from individuals strengthened the group as a whole. I 
saw in practice that you have to listen to the input of the 
team, or you’re going to do the project harm. 

And I also came to see that having these different 
perspectives grouped together, rather than randomly 
selecting teams, enhanced the entire exercise. For one 
thing, our productivity would have been much less 
because there would have been too much time spent 
saying, "I want to do it this way” and "Well, I want to do 
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it that way." The teams probably wouldn't have gotten as 
far as they did as fast. 

As a class, we did some work to make certain that 
we all understood our mission, that we shared a 
“common vocabulary" when it came to critical termi- 
nology, and that we understood what each team was 
going to produce. Then, the next night, the class broke 
into teams and worked independently on producing our 
main deliverable: a workflow that described how to find 
existing software, integrate it with new software, and 
produce code. 

During our last Enterprise meeting before talking to 
Mike, each team got up and presented their solutions. I 
had put together a management team and we set up 
selection criteria and produced an evaluation form that 
asked the class to rate each solution: Did the solution 
meet the requirements? Was the solution innovative? 
Was the solution feasible? 

Both the “pessimist" and the “optimist" teams, as we 
had come to call them, came up with strong solutions, 
and when we tallied up the class votes, their scores were 
close. One rated higher in innovation, the other in feasi- 
bility. Together, they offered a balanced approach. Our 
plan had been to down-select to one solution, but 
eventually we agreed to present both. 


After the three teams presented their solutions, the 
class voted. Though our team didn’t come out on top, we 
ran a close second. I listened to the discussion that 
followed the vote as the class planned the final 
presentation. After a while, I raised my hand. 


“Look,” I said, “there’s no doubt this team came up 
with a good approach, and they won in terms of the 
votes of the class. But there’s obviously merit in the 
other presentations, and I think it's going to be more 
beneficial to Mike Sander and the JPL organization if 
we present them with more than one path they might 
go down.” 

In the end, the class agreed to present two approaches 
to Mike — one dealt more with the development of 
software, the other with how to find what applicable 
software was already out there. 

I felt as though presenting both approaches was the 
right decision, and I think that Mike confirmed that the 
night that we delivered our solutions to him. After the 
first pitch, about approaches to software development, 
Mike sounded apprehensive. 

After the second presentation, he sounded more 
excited. It’s not that the presentation or the concept was 
better, but I think that he started to get a more complete 
picture of what we had to offer him. 

He made it very clear that he understood and 
appreciated the value in what we had prepared — to the 
point that he was going to share our input with his 
management. His response was gratifying. 

Bill Huddleston, NASA Headquarters 
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My job that last night, when we made our class 
presentation to Mike and to his deputy. Rich Doyle, was 
to summarize our work. Preparing for that summary, I 
became more aware of the shared concepts that the 
three teams had come up with, such as how to mitigate 
risk when dealing with flight code developed by people 
outside the Agency, and the importance of thinking 
beyond the immediate mission. 

1 think this was a good assignment. We got to 
experience an entire project from start to finish within 
a few days. That's an experience you don’t have in 
NASA because our projects take a long time. They’re 
huge. And they can be daunting, with so much at 
stake. Here, we had the freedom to explore the process 
itself and examine the roles involved. The Advanced 
Project Management class handed us a microcosm of 
a project that helped me, and 1 think others, to see the 
forest for the trees. • 




■ WENDY DOLCI is the Assistant Director of the NASA 
Astrobiology Institute at Ames Research Center. The 
Astrobiology Institute, established in July 1998, employs 
a multidisciplinary focus to bring together astronomers, 
biologists, chemists, exobiologists, geologists, and 
physicists. A key goal of the institute is to search for the origins of life — 
on Earth, elsewhere in our solar system, and beyond. 
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